home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1989 / Nov 89 / 0035-Re USES problems (lo-Nov89 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.2 KB  |  49 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    0724596                         3-Nov-89        18:59
  4.  
  5. From:   ATTACHMATE                      Attachmate, John Bartleson,PRT
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    Re- USES problems (long)
  10.  
  11. Greetings:
  12.  
  13. Here are the rules for determining USES dependencies:
  14.  
  15. 1.  If a symbol is referenced in the implementation of a UNIT, say Unit1, and
  16. the symbol is defined in the interface of Unit2, then Unit1 must USE Unit2.
  17.  
  18. 2.  If a symbol is referenced in the interface of Unit1, and defined in Unit2,
  19. then Unit1, AND ALL UNITS WHICH USE Unit1, must USE Unit2.  Furthermore, the
  20. units which USE Unit1 must USE Unit2 BEFORE they USE Unit1.
  21.  
  22. Now, when I say symbols, I am refering to types, variables and
  23. procedures/functions.  For variables and procedures/functions, one can get
  24. around this problem sometimes by using FORWARD statements.  This basically
  25. tells the compiler that the is a valid symbol which will be dealt with more
  26. thouroughly sometime later in the compile.  At the MacAppDA meeting in January
  27. 1989, it was proposed by TML to add FORWARD to Object declarations.  Is anyone
  28. aware of what happened to this idea?
  29.  
  30. You will often have problems with USES for interdependant Objects.  Luckily,
  31. most of the time I can massage the problem into the case where there is an
  32. acyclic graph of USES dependencies.  That is, take all of your Units and make
  33. them nodes.  Draw a directed edge between each Unit and the Units it USES.  If
  34. you have cycles, you have problems.  Of course, this ruins one of the best
  35. aspects (in my opinion) of OOL, namely systems are composed of interacting
  36. objects which can be arranged arbitrarily.  With Object Pascal, you must impose
  37. some structure on these interactions.
  38.  
  39. I think that this problem with USES is the single greatest reason why I would
  40. avoid developing with MacApp.  It is not by accident that UMacApp is one unit.
  41. It would be very ugly and nearly impossible to write if broken up into one unit
  42. per object (not that you have to, but that’s what makes sense to me).
  43.  
  44. Make your UNITS carefully because someday you may have to sleep in them.
  45.  
  46. John D. Rinaldo, Jr.
  47. Attachmate Corporation
  48.  
  49.